Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Periodicals/CSMP/C.S.M.P. Digest, Issue 3.019

Internet Message Format | 1994-06-09 | 87KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-019
Date: Mon, 25 Apr 94 11:11:52 MET DST

C.S.M.P. Digest             Mon, 25 Apr 94       Volume 3 : Issue 19

Today's Topics:

        C Source Code Wanted: Beginer Examples
        Decompressing JPEG images: Help!
        Mac Game Programming
        Mixed Mode Manager statistics gathering - is it possible?
        Pure virtual call from a dtor
        Symantec C++ 7.0 (Full)- Initial Impressions
        Symantec technical support not home
        System 7 Pro & Drag Mgr.
        Using PBCatSearch



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From Spiegs <[e-mail]>
Subject: C Source Code Wanted: Beginer Examples
Date: Fri, 1 Apr 1994 08:15:19 GMT
Organization: University of Minnesota, Twin Cities

I am a fairly novice C programmer. I am interested in obtaining all the C
source code I can obtain, preferably simple code for now.

I am looking for any FTP sites with C source code available to anonymous
users. Thanks.

BTW - I would spring for CodeWarrior in a hartbeat, if I had a CD-Rom.

Spiegs
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Fri, 1 Apr 1994 21:04:02 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Find the current MacFTP list and then connect to ftps on the list which
reportedly have lots of Mac files.  Stanford and the University of
Michigan have the "largest stock" of source code.  Look in their
development and source directories and there are enough examples to
either make you crave more or give up programming.

Check the ftp that's home to the alt.sources.mac newsgroup, as well.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Chuck Hoffman)
Date: Tue, 5 Apr 1994 12:43:49 GMT
Organization: GTE Laboratories

In article <[e-mail]>, Spiegs
<[e-mail]> wrote:

> I am a fairly novice C programmer. I am interested in obtaining all the C
> source code I can obtain, preferably simple code for now.
>
> I am looking for any FTP sites with C source code available to anonymous
> users. Thanks.
>

1.  There are good examples for beginners in "Macintosh C Programming
Primer, Volume 1, second edition" by Mark and Reed.  The book comes with a
diskette.

2.  There are several locations for Frequently Asked Questions (FAQs).
Some of the FAQs include code snippets.  You may be interested in these:

   ftp site:  rtfm.mit.edu
   directory:  /pub/usenet/news.answers/macintosh
   files (in order):
   1.  general
   2.  system
   3.  misc
   4.  apps

   ftp site:  ftp.cs.uoregon.edu
   directory:  /pub/mac
   files (in order):
   1.  csmp-faq-1
   2.  csmp-faq-2

   ftp site:  nada.kth.se
   directory:  /pub/hacks/mac-faq
   file:  CSMP_PD_FAQ

   ftp site:  soda.berkeley.edu
   directory:  /pub/jwang
   file:  av-general-faq.txt


3.  Chassis is a sample application shell upon which you can build other
applications.  Chassis is a good source of sample code.  Chassis is in the
following anonymous ftp locations.  Do not use the version at Stanford
University (sumex-aim) because it is not current, and is not 32-bit clean.
Use these, instead:

ftp.gte.com:
/pub/chuck/Chassis_6.0.sea.hqx

mac.archive.umich.edu:
/mac/development/source/chassis6.0.cpt.hqx

--
Chuck Hoffman
GTE Laboratories, Waltham, MA, USA
617-466-2131
- ------------------------------------------------
I'm not sure why we're here, but I am sure that
while we're here we're supposed to help each other.
- ------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Brian Bechtel)
Date: 9 Apr 1994 06:16:48 -0700
Organization: Apple Computer, Inc., Cupertino, California

Spiegs <[e-mail]> writes:

>I am a fairly novice C programmer. I am interested in obtaining all the C
>source code I can obtain, preferably simple code for now.

I have an html file (for Mosaic) on ftp.apple.com which points to
several major source code sites.  ftp.apple.com is not a MacHttp server,
so you have to grab the file directly.  The URL is
 file://ftp.apple.com/pub/blob/macsourcecode.html
I'd welcome additions or corrections.

Yes, I do plan to eventually have a HTTP server.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

---------------------------

>From [e-mail] (Chris Reid)
Subject: Decompressing JPEG images: Help!
Date: Wed, 06 Apr 1994 11:22:36 +0000
Organization: University of Strathclyde

Hi Netters,

I'm trying to decompress and display 32-bit JPEG images. I've (sort of)
figured out how to do this. The problem is, the image doesn't appear
on screen properly, because the palette isn't quite right. At the
same time, I'd like to convert it to PICT format. I'm using QuickTime
to do the 'dirty work' for me. The quality of the decompressed image
should be as high as possible. The destination screen is 8 bits deep.
Here's what I'm doing:


OpenCPicParams    header;
ImageDescriptionHandle    desc;
PicHandle thePic;

[Set up desc and get image dimensions (header.srcRect)]

/* Create a gWorld for the decompressed data */
e = NewGWorld(&theGWorld, (*desc)->depth, &header.srcRect, NULL, NULL, 0);

if (e != noErr)
{
    [blah, blah]
}

/* Set the port and open picture */

SetGWorld(theGWorld, NULL);
thePic = OpenCPicture(&header);


/* Now do the actual decompression */

e = FDecompressImage(
        data,
        desc,
        GetGWorldPixMap(theGWorld),
        &header.srcRect,
        NULL,
        ditherCopy,
        (RgnHandle) NULL,
        (PixMapHandle) NULL,
        (Rect *) NULL,
        codecMaxQuality,
        bestFidelityCodec,
        0,
        (DataProcRecordPtr) NULL,
        (ProgressProcRecordPtr) &myProgressRec);

if (e != noErr)
{
    [more blah, blah]
}

/* Done! */

ClosePicture();

/* Now get the (supposedly) ideal 8 bit palette */
/* popularMethod or medianMethod doesn't improve things, btw. */

e = GetPixMapInfo(GetGWorldPixMap(theGWorld), &thePictInfo, returnPalette,
                  256, systemMethod, 0);

[tidy up etc]

/* Display picture and set palette to match */

SetPalette(myWindow, thePictInfo.thePalette, TRUE);
DrawPicture(thePic, &(*thePic)->picFrame);


Everythings works, the picture displays fine. It's just not quite right.
The palette returned doesn't seem to fit the image. GifConverter manages
slightly better, JPEGView displays the image perfectly. What am I doing
wrong?

I'll be forever grateful for any hints or solutions! A deadline is looming.
Please e-mail me as our news server is *very* unreliable. I'll summarise
to the net, probably to alt.sources.mac if I can come up with some source
code.



Many thanks in advance,


Chris


PS: I can save my converted JPEG image in it's new PICT form. Again,
JPEGView
displays it like a charm. Aaron, how the heck do you do it :-)


+-----------------------------------------------------------------+
|Chris Reid                            e-mail: [e-mail] |
|Dept. Computer Science, Strathclyde University, Glasgow, Scotland|
+-----------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 11 Apr 94 17:13:12 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Chris Reid) writes:
>
> I'm trying to decompress and display 32-bit JPEG images. I've (sort of)
> figured out how to do this. The problem is, the image doesn't appear
> on screen properly, because the palette isn't quite right.
>
> /* Now get the (supposedly) ideal 8 bit palette */
> /* popularMethod or medianMethod doesn't improve things, btw. */
>
> e = GetPixMapInfo(GetGWorldPixMap(theGWorld), &thePictInfo, returnPalette,
>                   256, systemMethod, 0);

The basic problem is that the Picture Utilities package doesn't understand
anything about QuickTime-compressed PixMaps.

It's a pity. They did a good job of integrating QuickTime into all the rest
of QuickDraw, but they never got around to fixing this.

You could always decompress to a regular PixMap, do a GetPixMapInfo on this,
then go back and use that palette with the original compressed data.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

---------------------------

>From Shinya Fujimoto <[e-mail]>
Subject: Mac Game Programming
Date: Thu,  7 Apr 1994 13:33:28 -0400
Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

Hi,

I am not sure if this is the right place to post,
but if I'm wrong, please redirect me.

I am a beginner in Macintosh program and am now in
the step of programming a simple game.

I wonder if there is any good way to move objects around
the screen. I currently use scroll, but this becomes
extremely slow if the region is a little too big.
Redrawing the object will flash the object as it erases
and redraws.

Is there any good way??

Thanks!

    Takoyaki Master

- ---------------------------------
Shinya Fujimoto
Carnegie Mellon University
 Carnegie Institue of Technology
 Electrical & Computer Engineering

E-mail: [e-mail]
        [e-mail]
- ---------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Fri, 8 Apr 1994 10:38:53 GMT
Organization: Demon Internet

In article <[e-mail]>, Shinya Fujimoto
<[e-mail]> wrote:

> Hi,
>
> I am not sure if this is the right place to post,
> but if I'm wrong, please redirect me.
>
> I am a beginner in Macintosh program and am now in
> the step of programming a simple game.
>
> I wonder if there is any good way to move objects around
> the screen. I currently use scroll, but this becomes
> extremely slow if the region is a little too big.
> Redrawing the object will flash the object as it erases
> and redraws.
>
> Is there any good way??
>
> Thanks!
>
>     Takoyaki Master

     Don't worry, you're in the right place!

     The best way is to keep copying the graphic in the new position.
However, to avoid the flicker, you need to create an "offscreen graphics
world", as described in Inside Mac 6. Just think of it as a screen you
can't see. You draw all the graphics to this world, and then copy them all
onto the screen (in the new positions) using CopyBits, described in Inside
Mac 1 and 5.

     Let me know if I can be of more help!

     Alex

--
Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler

Internet, AOL, BIX: [e-mail]            "Surely you
AppleLink:          [e-mail]@internet#   can't be
CompuServe:         INTERNET:[e-mail]    serious?"
Delphi:             [e-mail]@inet#
FirstClass:         [e-mail],Internet   "I'm serious...
Fax (UK):           (0570) 45636                         and don't call
Fax (US / Canada):  011 44 570 45636                     me Shirley."

+++++++++++++++++++++++++++

>From [e-mail] (DEclipse)
Date: 7 Apr 1994 17:02:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, Shinya Fujimoto
<[e-mail]> writes:
>I wonder if there is any good way to move objects around
>the screen. I currently use scroll, but this becomes
>extremely slow if the region is a little too big.
>Redrawing the object will flash the object as it erases
>and redraws.

Well, I don't normally answer posts like this, but since it's for a CMU person
(I grad in '90), here's a start. It works for B & W, but you can change it to
color. Determine the size of the object you want to scroll, add twice the
maximum scroll amount for both horiz. and vert. So:
short H = ObjectH + 2 * DeltaH;
short V = ObjectV + 2 * DeltaV;
Translate H to bits and round to the nearest word:
short RowBytes = ((H +7) / 8 + 1) & 0xFFFE;
in non-optimized code. So you need a block of memory sized V * RowBytes.
Allocate this block and create a BitMap record. Set the fields in the BitMap
and set the base addr to the block of memory you allocated. Create a GrafPort.
SetPortBits to the BitMap. Get the oldPort, SetPort to the GrafPort, Draw your
object in the center of the BitMap, close the port, SetPort to the oldPort. Now
you can use CopyBits from the BitMap you created to qd.screenBits with the
appropriate rects and regions.

This is a lot of work, but the fastest compatible method. Keep your mask
regions nil or rects for speed. The white space around the objects is so that
you can erase the old image and copy the new image without having to call
EraseRect. (Calling EraseRect and then CopyBits isn't bad, but there may be
some minor flicker if the Rects overlap.)

Howard Fukuda

+++++++++++++++++++++++++++

>From Reid Ellis <[e-mail]>
Date: Sun, 10 Apr 1994 01:51:37 GMT
Organization: Alias Research, Inc., Toronto ON Canada

Shinya Fujimoto <[e-mail]> wrote:
|> I wonder if there is any good way to move objects around
|> the screen. I currently use scroll, but this becomes
|> extremely slow if the region is a little too big.
|> Redrawing the object will flash the object as it erases
|> and redraws.

Alex Metcalf <[e-mail]> writes:
|     The best way is to keep copying the graphic in the new position.
|However, to avoid the flicker, you need to create an "offscreen graphics
|world", as described in Inside Mac 6.

[..more good advice deleted]

An alternative is to use the SpriteWorld library, available at an FTP
site near you.  It handles very fast blitting of sprites around the
screen, using offscreen GWorlds and CopyBits() and even non-CopyBits()
[very *compatible* direct-to-screen memory access].

I haven't used it myself; these opinions have been formed by reading
feedback in this group over time.

Reid
--
- -
Reid Ellis, Alias Research Inc.
[phone] <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Sun, 10 Apr 1994 10:34:32 GMT
Organization: Demon Internet

In article <[e-mail]>, Reid Ellis <[e-mail]>
wrote:

> Shinya Fujimoto <[e-mail]> wrote:
> |> I wonder if there is any good way to move objects around
> |> the screen. I currently use scroll, but this becomes
> |> extremely slow if the region is a little too big.
> |> Redrawing the object will flash the object as it erases
> |> and redraws.
>
> Alex Metcalf <[e-mail]> writes:
> |     The best way is to keep copying the graphic in the new position.
> |However, to avoid the flicker, you need to create an "offscreen graphics
> |world", as described in Inside Mac 6.
>
> [..more good advice deleted]
>
> An alternative is to use the SpriteWorld library, available at an FTP
> site near you.  It handles very fast blitting of sprites around the
> screen, using offscreen GWorlds and CopyBits() and even non-CopyBits()
> [very *compatible* direct-to-screen memory access].
>
> I haven't used it myself; these opinions have been formed by reading
> feedback in this group over time.
>
> Reid

        The non-CopyBits direct screen memory access stuff isn't that hard....
the best place to start is to read the "Graphics" folder of the Mac Game
Developer's Handbook on the Developer CDs. It has loads of excellent
technotes relating directly to game development, such as non-CopyBits and
dithering graphics for mono screens.

     I could also post some code I've written in assembler: it copies a
rectangle from an offscreen world to either another offscreen world or to
the screen. It works quite well, and beats the hell out of CopyBits.

     Alex

--
Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler

Internet, AOL, BIX: [e-mail]            "Surely you
AppleLink:          [e-mail]@internet#   can't be
CompuServe:         INTERNET:[e-mail]    serious?"
Delphi:             [e-mail]@inet#
FirstClass:         [e-mail],Internet   "I am serious...
Fax (UK):           (0570) 45636                         and don't call
Fax (US / Canada):  011 44 570 45636                     me Shirley."

---------------------------

>From [e-mail] (Scott Barta)
Subject: Mixed Mode Manager statistics gathering - is it possible?
Date: 6 Apr 1994 09:58:08 -0400
Organization: The Ohio State University

I have been thinking for a while that a really neat app/init/cdev to write
for the PowerMacs would be one that sits on top of the Mixed Mode Manager
and gathers statistics for the number of mode switches that occur, the
amount of time the system spends emulated, the time spent native, the
overhead for a mode switch, etc.  The utility could collect stats for the
system as a whole and possibly by application.

Obviously it would greatly increase the overhead for a mode switch, so it
isn't something one would want running constantly, but it would be very
interesting and informative for those who are curious about what's going on
under the covers.

The question is, how could you do it?  I looked at the interface for the
MMM last night, and understandably, there isn't any sort of interface that
would allow you to patch in and install your own routines into a mode
switch.  (I think I can hear the Apple guys groaning somewhere in the
distance).  I tried tracing into some native traps with MacsBug, but,
little to my surprise, a 680X0 debugger didn't give me much help with
native code.

But I figure there must be a way, since it sounds like exactly the sort of
thing the Apple engineers would use while developing OS code on the
machine.  Anyone out there care to drop a hint or two (or perhaps bestow a
gift of the utility if it indeed exists)?

/************************************************************************/
/* Scott Barta                                                          */
/* Eisenhower National Clearinghouse                                    */
/* The Ohio State University                                            */
/* [e-mail]                                                       */
/************************************************************************/



+++++++++++++++++++++++++++

>From [e-mail] (John L. Scott)
Date: 6 Apr 1994 14:17:43 -0500
Organization: Self

In article <[e-mail]>,
[e-mail] (Scott Barta) wrote:

> Obviously it would greatly increase the overhead for a mode switch, so it
> isn't something one would want running constantly, but it would be very
> interesting and informative for those who are curious about what's going on
> under the covers.

Actually, the patch itself would only need to increment a couple of longs
each time a mode switch occurs.  That's not a great increase in overhead.

The application that monitors those longs could be set to update them every
second or so.  No great overhead there.

Sounds doable to me--if you can figure out what to hook into.

--John L. Scott

+++++++++++++++++++++++++++

>From Brian Strull <[e-mail]>
Date: Mon, 11 Apr 1994 22:43:27 GMT
Organization: Apple Computer, Inc.

The Macintosh Debugger for PowerPC, available with the Macintosh on RISC
SDK,
includes some features for performance gathering.

It uses pc sampling to give an estimate of % emulated time vs. % native
time,
and breaks native time up into which libraries you were in, and which
functions within libraries.  Since parts of the system are libraries, this
gives you some of the information you want.

This doesn't do everything you asked.  It doesn't count mixed mode
switches,
or measure absolute time spent on mixed mode overhead.

+++++++++++++++++++++++++++

>From [e-mail] (Tim Maroney)
Date: 11 Apr 94 20:52:51 GMT
Organization: As Little As Possible

In article <[e-mail]>
[e-mail] (Scott Barta) writes:
>I have been thinking for a while that a really neat app/init/cdev to write
>for the PowerMacs would be one that sits on top of the Mixed Mode Manager
>and gathers statistics for the number of mode switches that occur, the
>amount of time the system spends emulated, the time spent native, the
>overhead for a mode switch, etc.
>
>The question is, how could you do it?

Great idea!  Let's see, is it possible?  Here's a first stab at a design,
for which I make absolutely no promises:

(1) Use the millisecond timer for collecting statistics on time spent
    in each mode.  Your timer routine should merely increment a counter
    which will be used by the intercepts below.

(2) Detect mode switches from 68K->PPC by intercepting the mixed mode
    pseudo-trap in the 68K emulator.  A little challenging but you should
    be able to use a debugger to find out where the code you need to patch
    lives: just step through an execution of an instance of _MixedModeMagic.

(2a) Catching the return to 68K mode is tricky.  You'll need to either
    munge the switch stack frame to return to a routine that does
    the statistics gathering (see IM: PPC System Software, p. 2-11)
    or figure out what the Mixed Mode Manager does when it sees that bit
    and intercept the action another way.  The former is probably easier.
    Your intercept for _MixedModeMagic can push a return address to a 68K
    routine that will notice the mode switch back to 68K and then return
    to the caller of _MixedModeMagic.

(3) Detect mode switches from PPC-68K by the method in (2a) as well as by
    patching CallUniversalProc and CallOSTrapUniversalProc.  Again you
    will probably need to push a return-interception code address onto
    the stack.

(4) A drop-dead-easy Control Panel interface to turn the thing on and off
    and report the statistics, with an INIT to install these patches.

I'd give it about a week, maybe two weeks if the interception of
_MixedModeMagic turns out to be especially tricky.  But I haven't
looked into this in a real way at all, and this design might not work
for that reason.
--
Tim Maroney, Communications and User Interface Engineer
{apple!sun}!hoptoad!tim, [e-mail]

"God must be a Boogie Man." -- Joni Mitchell

---------------------------

>From [e-mail] (Robert S. Mah)
Subject: Pure virtual call from a dtor
Date: Sun, 03 Apr 1994 07:12:50 -0500
Organization: One Step Beyond

I have the following code...

  class Test{
    public:
      Test() { }
      virtual ~Test();
      virtual int Pure() = 0;
      virtual int Foo();
  };

  Test::~Test() { Pure(); }

  int Test::Foo() { return Pure(); }


In Symantec C++ (Mac v7.0) it returns the error...

  'Test::Pure' is a pure virtual function

in the d'tor.  If I use an empty d'tor, it compiles fine like it should.

However, Metrowerks C++ compiles the Pure() call in the d'tor without
complaining.

Which is right?  Is this legal C++ code?  I can't imagine why I can't call
a pure virtual function from a dtor, but C++ is a strange language...

Cheers,
Rob
________________________________________________________________________
 Robert S. Mah              One Step Beyond              [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Paul J. Lucas)
Date: Sun, 3 Apr 1994 19:55:48 GMT
Organization: AT&T

In <[e-mail]> [e-mail] (Robert S. Mah) writes:

>I have the following code...

>  class Test{
>    public:
>      Test() { }
>      virtual ~Test();
>      virtual int Pure() = 0;
>      virtual int Foo();
>  };

>  Test::~Test() { Pure(); }

>  int Test::Foo() { return Pure(); }


>In Symantec C++ (Mac v7.0) it returns the error...

>  'Test::Pure' is a pure virtual function

>in the d'tor.  If I use an empty d'tor, it compiles fine like it should.

>However, Metrowerks C++ compiles the Pure() call in the d'tor without
>complaining.

>Which is right?  Is this legal C++ code?  I can't imagine why I can't call
>a pure virtual function from a dtor, but C++ is a strange language...

    The code is legal.  I can find nothing forbidding it in the ARM;
    *con*structors are another matter.
--
    - Paul J. Lucas
      AT&T Bell Laboratories
      Naperville, IL

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 3 Apr 94 23:51:00
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Paul J. Lucas) writes:
> In <[e-mail]> [e-mail] (Robert S. Mah) writes:

>>I have the following code...

>>  class Test{
>>    public:
>>      Test() { }
>>      virtual ~Test();
>>      virtual int Pure() = 0;
>>      virtual int Foo();
>>  };

>>  Test::~Test() { Pure(); }

>>  int Test::Foo() { return Pure(); }


>>In Symantec C++ (Mac v7.0) it returns the error...

>>  'Test::Pure' is a pure virtual function

>>in the d'tor.  If I use an empty d'tor, it compiles fine like it should.

>>However, Metrowerks C++ compiles the Pure() call in the d'tor without
>>complaining.

>>Which is right?  Is this legal C++ code?  I can't imagine why I can't call
>>a pure virtual function from a dtor, but C++ is a strange language...

>     The code is legal.  I can find nothing forbidding it in the ARM;
>     *con*structors are another matter.

I think we have different readings of ARM 12.7, pg. 294, then:
# Member functions may be called in constructors and destructors. This implies
# that virtual functions may be called (directly or indirectly). The function
# called will be the one defined in the constructor's (or destructor's) own
# class or its bases, but *not* any function overriding it in a derived class.
# This ensures that unconstructed objects will not be accessed during
# construction or destruction.

While the sentence on page 295 talking about pure virtuals only talks about
constructors, it seems clear to me that it applies equally to destructors,
and thus Symantec C++ is IMHO right (as a syntax checker, SC++ definitely
has its merits :-).

This behavior makes perfect sense: Once a virtual destructor is called, any
of the "derived objects" have already been destructed and thus their "class
invariants" no longer hold, which makes calling members defined there very
dangerous.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
   "Evidently the cleaning lady found him slumped over his Macintosh"
                               -- Jay McInerney, _Brightness Falls_


+++++++++++++++++++++++++++

>From [e-mail] (Paul J. Lucas)
Date: Sun, 3 Apr 1994 22:42:41 GMT
Organization: AT&T

In <[e-mail]> [e-mail] (Matthias Neeracher) writes:

>In article <[e-mail]>, [e-mail] (Paul J. Lucas) writes:
>> In <[e-mail]> [e-mail] (Robert S. Mah) writes:

>>>I have the following code...

>>>  class Test{
>>>    public:
>>>      Test() { }
>>>      virtual ~Test();
>>>      virtual int Pure() = 0;
>>>      virtual int Foo();
>>>  };

>>>  Test::~Test() { Pure(); }

>>>  int Test::Foo() { return Pure(); }


>>>In Symantec C++ (Mac v7.0) it returns the error...

>>>  'Test::Pure' is a pure virtual function

>>>in the d'tor.  If I use an empty d'tor, it compiles fine like it should.

>>>However, Metrowerks C++ compiles the Pure() call in the d'tor without
>>>complaining.

>>>Which is right?  Is this legal C++ code?  I can't imagine why I can't call
>>>a pure virtual function from a dtor, but C++ is a strange language...

>>     The code is legal.  I can find nothing forbidding it in the ARM;
>>     *con*structors are another matter.

>I think we have different readings of ARM 12.7, pg. 294, then:
># Member functions may be called in constructors and destructors. This implies
># that virtual functions may be called (directly or indirectly). The function
># called will be the one defined in the constructor's (or destructor's) own
># class or its bases, but *not* any function overriding it in a derived class.
># This ensures that unconstructed objects will not be accessed during
># construction or destruction.

>While the sentence on page 295 talking about pure virtuals only talks about
>constructors,

    Bingo!

>it seems clear to me that it applies equally to destructors,

    There is no room for supposition.  It either says it or it doesn't.
    Given that it is not expressly forbidden, it is allowed.

>This behavior makes perfect sense: Once a virtual destructor is called, any
>of the "derived objects" have already been destructed and thus their "class
>invariants" no longer hold, which makes calling members defined there very
>dangerous.

    While the poster's code has a virtual destructor, that's not the
    issue; the issue is whether a pure virtual *function* can be
    called from a destructor.  Since objects are destroyed bottom
    up, the most-derived function *can* be called it seems.
    Obviously, this is not true for CONstruction since the most
    derived part hasn't been constructed yet.

    So perhaps the "omission" in the ARM is intentional.
--
    - Paul J. Lucas
      AT&T Bell Laboratories
      Naperville, IL

+++++++++++++++++++++++++++

>From [e-mail] (David Sachs)
Date: 3 Apr 1994 17:52:56 -0500
Organization: FERMILAB, Batavia, IL

It is perfectly legal (from the compiler's point of view) to call
a function, that has been declared as pure virtual, either by
calling the function directly or indirectly from a constructor
or destructor, or by calling the function with an explicit scope
qualifier.

The C++ language permits explicitly defining a function that has
been declared as pure virtual, specifically for the purpose of
supporting such calls.

If a pure virtual function, which has NOT been defined, is called,
the effects at run time are unspecified. Two common methods used
by various C++ implementations are:

  Execute random garbage or generate an immidiate failure by
  jumping to location 0.

  Execute a function that prints a message about the improper
  call and ends the program.

+++++++++++++++++++++++++++

>From [e-mail] (Bob Zimmerman)
Date: 3 Apr 1994 15:46:20 GMT
Organization: InterAccess, Chicagoland's Full Service Internet Provider

Robert S. Mah ([e-mail]) wrote:
> I have the following code...

>   class Test{
>     public:
>       Test() { }
>       virtual ~Test();
>       virtual int Pure() = 0;
>       virtual int Foo();
>   };

>   Test::~Test() { Pure(); }
> In Symantec C++ (Mac v7.0) it returns the error...
>   'Test::Pure' is a pure virtual function
> in the d'tor.  If I use an empty d'tor, it compiles fine like it should.
> Which is right?  Is this legal C++ code?  I can't imagine why I can't call
> a pure virtual function from a dtor, but C++ is a strange language...

One reason the compiler could be complaining is: A Destructor will call
all of the "sub-classes" destructors... and the compiler is concerned
that these destructors... will have "thrown away" information needed by
the pure virtual funciton... This (IMHO) isn't valid for the compiler to
enforce in a d'tor since the order of execution is that the current d'tor
runs first (destroying local stack stuff - as opposed to a sub-classs) so
the sub-class stuff should always be available.

I know in the constructor - this is definilty true... I am not sure why
it would be enforced for the d'tor...

--
- -------------------------------------------------
| Bob Zimmerman   [e-mail]          |
|        Voice:   [phone]                  |
|                                                 |
| If it's worth reading,                          |
|             you found it on Internet!           |
- -------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Robert Martin)
Date: Mon, 4 Apr 1994 15:28:47 GMT
Organization: R. C. M. Consulting Inc. 708-918-1004

[e-mail] (Robert S. Mah) writes:
>  class Test{
>    public:
>      virtual ~Test();
>      virtual int Pure() = 0;
>  };

>  Test::~Test() { Pure(); }

>Is this legal C++ code?

No.  It is illegal to call a pure virtual function from either a
constructor or destructor.  The reason is simple.  When constructing a
derived class, the base class constructor is called first.  While it
is executing the object under construction is an instance of the
"base" NOT an instance of the derived (in fact the vtbl pointer is set
at the vtbl for the base class).  Thus there IS NO IMPLEMENTATION for
the pure function.

C++ has a rule.  No member function will ever be called unless all the
bases and members for that class have been constructed first.  If a
constructor could call and deploy a virtual function to a class lower
in the hierarchy than the currently executing constructor, then this
rule would be violated.

Moral:  Don't call pure virtual functions from constructors or
destructors.  Period.

--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| [e-mail]  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: [phone] |   Object Oriented Design
Green Oaks IL 60048 | Fax: [phone] |   C++

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 5 Apr 94 16:49:40
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Paul J. Lucas) writes:

> In <[e-mail]> [e-mail] (Matthias Neeracher) writes:

>>In article <[e-mail]>, [e-mail] (Paul J. Lucas) writes:
>>> In <[e-mail]> [e-mail] (Robert S. Mah) writes:

>>>>Which is right?  Is this legal C++ code?  I can't imagine why I can't call
>>>>a pure virtual function from a dtor, but C++ is a strange language...

>>>     The code is legal.  I can find nothing forbidding it in the ARM;
>>>     *con*structors are another matter.

>>I think we have different readings of ARM 12.7, pg. 294, then:
>># Member functions may be called in constructors and destructors. This implies
>># that virtual functions may be called (directly or indirectly). The function
>># called will be the one defined in the constructor's (or destructor's) own
>># class or its bases, but *not* any function overriding it in a derived class.
>># This ensures that unconstructed objects will not be accessed during
>># construction or destruction.
[...]
>>This behavior makes perfect sense: Once a virtual destructor is called, any
>>of the "derived objects" have already been destructed and thus their "class
>>invariants" no longer hold, which makes calling members defined there very
>>dangerous.

>     While the poster's code has a virtual destructor, that's not the
>     issue; the issue is whether a pure virtual *function* can be
>     called from a destructor.  Since objects are destroyed bottom
>     up, the most-derived function *can* be called it seems.

I'm not sure what you mean by "bottom up". The destructor calling order is
exactly the opposite of the constructor calling order, so at the time the
virtual destructor is called, the most-derived function definitely *cannot* be
called. Look again at the ARM quote above:

# The function called will be the one defined in the constructor's (or
# destructor's) own class [...] but *not* any function overriding it [...]

>     Obviously, this is not true for CONstruction since the most
>     derived part hasn't been constructed yet.

And because at DEstruction time, the derived part is not constructed *anymore*,
the same argument applies there.

>     So perhaps the "omission" in the ARM is intentional.

Since we are arguing about the ARM rather than the Old Testament here, I am
more inclined to consider this an unintentional imprecision. No matter what is
and is not mentioned on page 295, the language quoted above from page 294 makes
it clear that a call from the destructor could only call the pure virtual,
and that is undefined even if page 295 doesn't explicitly say so.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
  "Johannes Scotus Eriugena, the greatest European philosopher of the 9th
   century, said that if reason and authority conflict, reason should be
   given preference. And if that doesn't sound reasonable to you, you'll
   just have to accept it..."







+++++++++++++++++++++++++++

>From [e-mail] (Robert Martin)
Date: Tue, 5 Apr 1994 14:00:07 GMT
Organization: R. C. M. Consulting Inc. 708-918-1004

[e-mail] (Paul J. Lucas) writes:

[regarding the calling of pure virtual functions from destructors...]
>    There is no room for supposition.  It either says it or it doesn't.
>    Given that it is not expressly forbidden, it is allowed.

Bah.  This is a fine example of legalism clouding rational thought.

>    [...]the issue is whether a pure virtual *function* can be
>    called from a destructor.  Since objects are destroyed bottom
>    up, the most-derived function *can* be called it seems.
>    Obviously, this is not true for CONstruction since the most
>    derived part hasn't been constructed yet.

>    So perhaps the "omission" in the ARM is intentional.

No.  The "most-derived" function is unimplemented when a PVF is called
from its own destructor.  The concrete object being destroyed has
already be partially destructed.  The class that provided the
implementation for the PVF no longer exists.

While it is true that the ARM does not explicitly disallow calling
PVFs from destructors, I think it is clear that this is an omission,
and not intended to imply that calling PVFs from destructors is either
legal or advisable.

There is a "hint" in the ARM regarding this.  Section 12.1, in the
commentary, "...virtual functions will work only after construction
and before destruction of an object..."

The bottom line, in any case, is that if you call a PVF from a
destructor, your program will crash.  That, I think, is the most
powerful indictment of all.

--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| [e-mail]  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: [phone] |   Object Oriented Design
Green Oaks IL 60048 | Fax: [phone] |   C++

+++++++++++++++++++++++++++

>From [e-mail] (James Kanze)
Date: 05 Apr 1994 19:30:55 GMT
Organization: SEL

In article <[e-mail]> [e-mail]
(Paul J. Lucas) writes:

|> In <[e-mail]> [e-mail] (Matthias Neeracher) writes:

|> >In article <[e-mail]>, [e-mail] (Paul J. Lucas) writes:
|> >> In <[e-mail]> [e-mail] (Robert S. Mah) writes:

|> >>>I have the following code...

|> >>>  class Test{
|> >>>    public:
|> >>>      Test() { }
|> >>>      virtual ~Test();
|> >>>      virtual int Pure() = 0;
|> >>>      virtual int Foo();
|> >>>  };

|> >>>  Test::~Test() { Pure(); }

|> >>>  int Test::Foo() { return Pure(); }


|> >>>In Symantec C++ (Mac v7.0) it returns the error...

|> >>>  'Test::Pure' is a pure virtual function

|> >>>in the d'tor.  If I use an empty d'tor, it compiles fine like it should.

|> >>>However, Metrowerks C++ compiles the Pure() call in the d'tor without
|> >>>complaining.

|> >>>Which is right?  Is this legal C++ code?  I can't imagine why I can't call
|> >>>a pure virtual function from a dtor, but C++ is a strange language...

|> >>     The code is legal.  I can find nothing forbidding it in the ARM;
|> >>     *con*structors are another matter.

|> >I think we have different readings of ARM 12.7, pg. 294, then:
|> ># Member functions may be called in constructors and destructors. This implies
|> ># that virtual functions may be called (directly or indirectly). The function
|> ># called will be the one defined in the constructor's (or destructor's) own
|> ># class or its bases, but *not* any function overriding it in a derived class.
|> ># This ensures that unconstructed objects will not be accessed during
|> ># construction or destruction.

|> >While the sentence on page 295 talking about pure virtuals only talks about
|> >constructors,

|>     Bingo!

|> >it seems clear to me that it applies equally to destructors,

|>     There is no room for supposition.  It either says it or it doesn't.
|>     Given that it is not expressly forbidden, it is allowed.

|> >This behavior makes perfect sense: Once a virtual destructor is called, any
|> >of the "derived objects" have already been destructed and thus their "class
|> >invariants" no longer hold, which makes calling members defined there very
|> >dangerous.

|>     While the poster's code has a virtual destructor, that's not the
|>     issue; the issue is whether a pure virtual *function* can be
|>     called from a destructor.  Since objects are destroyed bottom
|>     up, the most-derived function *can* be called it seems.
|>     Obviously, this is not true for CONstruction since the most
|>     derived part hasn't been constructed yet.

Since when are objects destroyed bottom up?  The most derived class is
destructed first, then the next, and the base class is destructed
last.  (Destruction is in the opposite order of construction.)

In particular, when executing the destructor for a class, all derived
classes have already been destructed.

|>     So perhaps the "omission" in the ARM is intentional.

I don't think so.
--
James Kanze                       email: [e-mail]
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

+++++++++++++++++++++++++++

>From [e-mail] (Tom Moertel)
Date: 5 Apr 1994 18:59:34 -0400
Organization: MSA, Inc., CSG Technologies Division

Robert S. Mah ([e-mail]) wrote:
: I have the following code...
:
:   class Test{
:     public:
:       Test() { }
:       virtual ~Test();
:       virtual int Pure() = 0;
:       virtual int Foo();
:   };
:
:   Test::~Test() { Pure(); }
:
:   int Test::Foo() { return Pure(); }


: In Symantec C++ (Mac v7.0) it returns the error...
:   'Test::Pure' is a pure virtual function
: in the d'tor.  If I use an empty d'tor, it compiles fine like it should.

[Snip]

: Which is right?  Is this legal C++ code?  I can't imagine why I can't call
: a pure virtual function from a dtor, but C++ is a strange language...


Strictly speaking, it's legal, but like calls from constructors, calls
from destructors do not use virtual lookup to call member functions of
derived classes.  For example, calling Pure() from Test's destructor
is equivalent to calling Test::Pure().  When SC++ complains about
calling a pure virtual function from a destructor, it's actually
trying to do you a favor.  It reasons that because Pure() is pure
virtual, Test::Pure() doesn't exist (faulty conclusion), and therefore
you have made a mistake.

What's weird is that if you actually define Test::Pure(), which
is a perfectly legitimate thing to do, SC++ still gives you the
error.  There is a solution, however: just call Test::Pure()
explicitly.  Not only does this work, it helps readers of your
code better understand what is really happening.

I've tried this, and it works fine:

class Test
{
    virtual int Pure() = 0;
    virtual ~Test();
};

int Test::Pure() { return 0; }
Test::~Test() { Test::Pure(); }

// doesn't compile: Test::~Test() { Pure(); }

--
Tom Moertel                          Interests:  Software Engineering,
                                                 Symbolic Mathematics,
MSA, CSG Technologies Division                   Algorithms,
[e-mail]                             Itchy-Scratchy Theory.

+++++++++++++++++++++++++++

>From Reid Ellis <[e-mail]>
Date: Sat, 9 Apr 1994 21:17:33 GMT
Organization: Alias Research, Inc., Toronto ON Canada

Robert Mah <[e-mail]> wrote:
|I have the following code...
|
|  class Test{
|    public:
|      Test() { }
|      virtual ~Test();
|      virtual int Pure() = 0;
|      virtual int Foo();
|  };
|
|  Test::~Test() { Pure(); }
|
|  int Test::Foo() { return Pure(); }
|
|In Symantec C++ (Mac v7.0) it returns the error...
|  'Test::Pure' is a pure virtual function
|in the d'tor.  If I use an empty d'tor, it compiles fine like it should.

In "The C++ Programming Language, 2nd Edition", in section r.12.7 [p
582] it talks about constructors [but not destructors] and pure
virtual methods:

            The effect of calling a pure virtual function directly or
            indirectly for the object being constructed from a
            constructor, except using explicit qualification, is
            undefined (see section r.10.3).

In every other case w.r.t. virtual functions, constructors and
destructors mirror each other, so I would gather that this case is no
exception.  Seems like Symantec C++ is justified in signalling an
error.  Other implementations may do other things, since this use is
explicitly "undefined".  Making it an error keeps you from writing
non-portable code, IMHO.

Reid
--
- -
Reid Ellis, Alias Research Inc.
[phone] <[e-mail]>

---------------------------

>From [e-mail] (RadicalLib)
Subject: Symantec C++ 7.0 (Full)- Initial Impressions
Date: 8 Apr 1994 16:58:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

     I haven't had time to evaluate the new state of the C++ translator, or
other compile/code-generation issues... But here's some comments for what they
are worth.

     The THINK Project Manager hasn't changed much.  The addition of a
trivially configurable scripts menu being the major, and a welcome, change.
One minor change that I think will also be welcomed is a Preferences dialog for
C++ Warnings... Every warning is now individually toggleable.

     It is in the additions, (those things only in the $150 upgrade, NOT in the
free update), that things get interesting...

     1) THINK Class Library 2.0 - What we've been waiting for:  A true C++
application framework.  Since this is real C++, the TCL is no longer supported
by the C compiler... C TCL users will have to stick with 1.1.3.  Some features:
     -Real constructors and destructors, (the old IClassName methods are still
there for backwards compatibility).
     -Multiple inheritance is used in the TCL.
     -Exceptions are supported via macros, which will smoothly become native
exception handling when they introduce it in the compiler.
     -A large subset of the proposed Run-Time Type Identification (RTTI)
standard is also implemented in macros.  See section 13.5 in The C++
Programming Language, 2nd Ed. by Stroustrup for an explanation of the
usefulness of RTTI, if you are unfamiliar with this.
     -A new feature called Object I/O provides an IOStream-based binary object
reading/writing mechanism.
     -A new class called CSaver is built with Object I/O to provide persistence
for documents, (e.g. window size and position are stored with saved documents
auto-magically).
     -Apple Event support is now comprehensive: For example, the new TCL
starter app, AEStarter, is now scriptable, recordable, has 15 Apple Events
besides the Required Suite and 13 AE Classes.  A few examples of the new Events
and classes: move, delete, duplicate, close, application, character, document,
file and word.  Seems like a pretty nice base-line to me.

     2) THINK Inspector - Anyone who has already been doing object-oriented
programming will immediately recognize a new best friend.  What we'd been doing
already by a lot of dereferencing and typing is now handled in a smooth and
user-friendly fashion by this application which can be launched from the THINK
Debugger.
     Each Inspector window provides three panes: A Class pane, a Data pane and
a Function pane.
     -By clicking on "::" in the Class pane you see your global functions.
     -By double-clicking on a function in the Function pane the debugger Code
window goes to that function's code.
     -If you select a class name in the Class pane, the class's methods are
displayed in the Function window and any current instances are displayed in the
data window.
     -Objects displayed in the data window have a triangle... Which, when
turned down, shows you the name and current value of the object's members.
     -If one of the object's members is itself an object, it also has a
triangle.
     -One or more non-contiguous selections can be made of member data, which
you can then bump over to the debugger's Data window... Though there is a
slight bug with this and data members of type double, (it's reported and
acknowledged by Symantec).
     -When an object is selected in the Inspector's Data window, you can have
the Inspector go to the line of code that was responsible for allocating the
object.  (!)
     -By doing a "Select All" in the Class pane, ALL current objects will be
displayed.  Yes, that includes those that aren't pointed to by anything.  (!!)
     -The Inspector is a user-interface triumph.  There is NO typing at all in
the Inspector, everything is clicked, using interface elements we already know
and love.

     3) Visual Architect- This application provides a resource building
environment similar to ResEdit/AppMaker with the code generation capabilities I
am familiar with from AppMaker.  But it's a lot more powerful.  Explicitly
based on the TCL, it facilitates the derivation of new classes for custom
interface elements/views.  Basically, if you ObjectThink you'll love this
application builder.  A couple observations:
     -It is well integrated with the THINK Project Manager, even going so far
as to close files that are open in the TPM which it is about to re-generate,
(Apple Events begin to really pay off!).
     -Has double-file generation, like AppMaker, so that for each new class
introduced there are two files generated, one for your custom code, (the
higher-level file), one with code that is entirely written by the Visual
Architect, (the lower-level file).
     -The lower-level files, which in AppMaker are called p-files for the p in
the filename that denotes them, are denoted with a prepended "x_" by the Visual
Architect which will undoubtedly lead to them being called the x files, (pun
surely intended).
     -Has excellent Balloon Help support.
     -Has the usual stuff we expect from this sort of thing: a tear-off Tools
menu, good Alignment support, drawing tools, etc.


     I've suffered as much as anyone with the buggy C++ 6.0 release.  But all
in all, this release is well on its way to restoring my faith.  I think the
Inspector, in particular, will really raise the bar on the sort of help we
start to expect from our Macintosh development tools.

    I am
       Radical Liberation.

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sun, 10 Apr 1994 05:16:07 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

     What are the new manuals like?

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (RadicalLib)
Date: 11 Apr 1994 02:55:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (John Nagle) writes:

>     What are the new manuals like?

Very big.  And quite improved.  I was going through the tutorials to learn the
Visual Architect and was having a fairly fun time.  The section to help you
begin to understand the TCL is much better than before, (I wish it had been
there when I was trying to get over that initial learning hump).  Otherwise,
the new manuals are pretty much like the 6.0 manuals... even the same cover
design.


---------------------------

>From [e-mail] (Scott W. Haney)
Subject: Symantec technical support not home
Date: 29 Mar 94 20:13:55 GMT
Organization: Magnetic Fusion Energy - LLNL

  I received a flier from Symantec advertising C++ version 7.0 and had
some problems parsing the marketing-speak description of the features.
Foolishly thinking that they'd be happy to help out a long-time
customer who was thinking about spending $250 on their products (7.0
upgrade + PPC kit), I thought I call them up to find out more about
these features. I called there NON-toll-free number and, after
listening to a long announcement about how they were going to start
charging me for technical support, I got a person who the phone menu
said knew about "product information". Unfortunately, the "product
information" I asked for was too specific so they said I must talk to
technical support. I asked if they could transfer me and they said they
couldn't. OK, I called the number again and listend to the long message
and chose the technical support option. I stayed on hold for 30 minutes
(yes you read that right) and never got to talk to a person (although I
did get to listen to a lot of elevator music and hear the message "your
phone call is very important to us" about 200 times). I called back customer
support and calmly explained that I couldn't get through to customer support
so could I leave a number so they could get back to me. I was informed that
with the new "fee-for-support" plan, they never did call-backs, even to
give information to potential customers. I then asked the customer support rep.
what I should do to get my question answered and she said my only option was
to talk to technical support. Since I had already, I thought, made a reasonable
attempt to do this I asked to talk to her supervisor. Unfortunately, he
was at lunch. I asked if I could leave my number for him to call me back.
She said he wouldn't call me back and reminded me that they offer a 60 day
money back guarantee, so why didn't I just buy the product and if it didn't
have the features I needed I could get a refund. Remaining calm, I said
that I wouldn't do business with Symantec under these circumstances. She
said she was sorry to hear that but there was nothing she could do.
  I've seen Symantec get flamed almost continuously for the past several months
and, quite frankly, I thought some of it was a bit unfair. However, this
experience has left me feeling that the company doesn't really care very
much about keeping customers. In particular, I've never before had a company
make me jump through hoops in order to get info about a product.
  I'm fairly close to deciding not to give Symantec any more of my business.
However, I'm willing to grant that I hit a bad day in technical support land
and give Symantec another chance. Therefore, I wonder if someone from Symantec
could contact me via email to answer a few brief questions about the THINK
Project Manager.

Scott


--
- -----------------------------------------------------------------------
Scott W. Haney        || Lawrence Livermore N'Lab || The above views are
[e-mail] || P.O. Box 808;  L-637     || mine and not neces-
[phone]        || Livermore, CA  94550     || sarily LLNL's.

+++++++++++++++++++++++++++

>From [e-mail] (Bill Stackhouse)
Date: 29 Mar 1994 23:39:37 GMT
Organization: Informix Software, Inc.

In article <haney.764972035@maverick> [e-mail] (Scott W. Haney) writes:
>  I received a flier from Symantec advertising C++ version 7.0 and had
>some problems parsing the marketing-speak description of the features.
>Foolishly thinking that they'd be happy to help out a long-time
>customer who was thinking about spending $250 on their products (7.0
>upgrade + PPC kit), I thought I call them up to find out more about
>these features. I called there NON-toll-free number and, after

[bunch of complaints deleted]

Phil Shapiro is a great resource and always gets a response back to me
in short order. His email address is [e-mail]  If you
read the programming group, you know about Phil. You should have tried
him first since you probably knew that your questions were more
technical than could be answered by a sales person. Did you do that just
to have a reason to complain?

Yes they handled the call very badly and I would have been pissed off.
If you had had a real technical support question and not a sales question
I bet you could have gotten it answered.

If you have been a Think C user, you have a good feel for what any
version of Think C will look like. The 60 day MBG is a great way to
test drive the new version if you have some nagging unanswered
questions.  It sounds like the person handled that part correctly given
that tech support was not an option and this person did not have an
answer for you.  May be she/he should have but they did not. They
probably get 100's of calls a day and many of them from people that
probably never planned to buy. They have to make a business decission
about how to allocate their dollars.

Faning the flames does not help anyone. If you don't like Symantec
then you just don't like them. There are many people who still do.
Except for some C++ bugs, Think C is still a great product.

Again, give Phil some direct questions and see if that helps.

Flame me if you want, I will not listen. I am tired of the petty
complaints over the upgrage fees and what a bad product Think C
has become. $150/$250 is cheap if you are doing real development
and if you are just playing around, then stick with version 6.
There are some of us that have to have one of each compiler so that
the others can have development tools.

Bill



+++++++++++++++++++++++++++

>From [e-mail] (mahboud)
Date: Tue, 29 Mar 1994 16:26:38 -0800
Organization: AG Group, Inc.

In article <haney.764972035@maverick>, [e-mail] (Scott W.
Haney) wrote:

>   [description of hellish phone experience]
> Scott
>
>

Scott, please let us know what you find out.

I am tempted to go through and print out all the flames and mail them to
Symantec.  Maybe that'll wake them up.

I have had similar experience with calling Symantec.  I had a profiler
problem with THINK C and after being on the phone for quite a long time,
the person answering couldn't help me (he read me some passages out of the
manual!) and told me that there is no one there who know much about the
profiler.

And they expect us to start paying for this sort of service??

-mahboud
- -------------------------------------------------------------
Mahboud Zabetian
[e-mail]
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp

+++++++++++++++++++++++++++

>From [e-mail] (Howard Berkey)
Date: Wed, 30 Mar 1994 04:57:09 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <haney.764972035@maverick> [e-mail] (Scott W. Haney) writes:
[unfortunately typical tale of Symantec phone support woe deleted]

>  I've seen Symantec get flamed almost continuously for the past several months
>and, quite frankly, I thought some of it was a bit unfair. However, this
>experience has left me feeling that the company doesn't really care very
>much about keeping customers. In particular, I've never before had a company
>make me jump through hoops in order to get info about a product.

While your story is pretty ugly, and indeed I'm saddened (but not
surprised) to hear that Symantec is now charging for tech support on a
product which (in general) requires it to some extent, all I can say
is if you think that was bad try dealing with IBM sales sometime.

At work I had to talk to a salesman for 30 minutes once just trying to
convince him that I had a RS/6000 when all I wanted to buy was an OS
upgrade or something similar.  The conversation went something like:

Sales droid:  "I'm veree sorree, all we show at your site are AS/400
computers."

Me:  "Trust me.  I develop on this RS/6000 for a living.  Here's what
uname -a says.  Here's the serial number. [etc]".

Sales droid: "Please hold."

(5 mins later)

Droid:  "I'm veree sorree..."

That went on for a half hr. until he got ahold of our regular sales
rep.

So good luck with Symantec... at least they believe you when you call
:-)

-H-




--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                                             [e-mail]
                            Kill the Wabbit!

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 30 Mar 1994 07:53:19 GMT
Organization: The Royal Institute of Technology

In <haney.764972035@maverick> [e-mail] (Scott W. Haney) writes:

>  I'm fairly close to deciding not to give Symantec any more of my business.
>However, I'm willing to grant that I hit a bad day in technical support land
>and give Symantec another chance. Therefore, I wonder if someone from Symantec

Actually, I think you hit the bad product for Symantec.
Symantec should be selling word processors, mail applications
and project organization chart drawing programs, not development
tools. They should separate out development tools into a whole
subsidiary company, with its OWN support channels, management,
marketing budget, ...

That's about the only way they can believably stay at the forefront
of the tools business.
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
    Not speaking for the Liberian Government.

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 30 Mar 1994 07:56:09 GMT
Organization: The Royal Institute of Technology

In <2nae7p$[e-mail]> [e-mail] (Bill Stackhouse) writes:

>Phil Shapiro is a great resource and always gets a response back to me
>in short order. His email address is [e-mail]  If you

>Again, give Phil some direct questions and see if that helps.

I would say DON'T.

Phil works on the compiler.

He has better things to do than answering technical support letters.

The only time I sent a direct letter was regarding some reproducible
bug in the compiler which didn't quite make it through the normal tech
support channels.

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
    Not speaking for the Liberian Government.

+++++++++++++++++++++++++++

>From [e-mail] (Scott W. Haney)
Date: 30 Mar 94 16:42:03 GMT
Organization: Magnetic Fusion Energy - LLNL

[e-mail] (Bill Stackhouse) writes:

>In article <haney.764972035@maverick> [e-mail] (Scott W. Haney) writes:
>>  I received a flier from Symantec advertising C++ version 7.0 and had
>>some problems parsing the marketing-speak description of the features.
>>Foolishly thinking that they'd be happy to help out a long-time
>>customer who was thinking about spending $250 on their products (7.0
>>upgrade + PPC kit), I thought I call them up to find out more about
>>these features. I called there NON-toll-free number and, after

>[bunch of complaints deleted]

>Phil Shapiro is a great resource and always gets a response back to me
>in short order. His email address is [e-mail]  If you
>read the programming group, you know about Phil. You should have tried
>him first since you probably knew that your questions were more
>technical than could be answered by a sales person. Did you do that just
>to have a reason to complain?

Bill,

  I think you misunderstood my message. Let me explain.
  Over the past few years I *have* sent mail, usually from CompuServe,
to people at Symantec, including Phil Shapiro. Generally, I did not receive
a reply. The messages were generally questions or comments, written
civilly. I don't hold the lack of replies against Symantec, I simply
determined that this was not a good way to get my questions answered.
Apparently your experience has been different. Fair enough.
  Second, I spent 1/2 on hold waiting for TECHNICAL support. Contrary to
your assertion, they were the correct people to answer my question.
Furthermore, they have promptly answered this sort of question for me
in the past.
  Third, I called Symantec with the inclination to plunk down $250 bucks
on the 7.0+PPC upgrade. Believe me, I have much better things to do with my
time than sit on the phone for an hour listening to music. Symantec would
have my order now if I could have simply talked to a person who was willing
to get about 5 minutes of technical questions answered.

>Yes they handled the call very badly and I would have been pissed off.
>If you had had a real technical support question and not a sales question
>I bet you could have gotten it answered.

I called the Technical support line three times. When you call Symantec
Technical Support you go through a phone menu in order
to have your call directed. The 1st time I called I chose customer service
(option 2). I was told they only knew general information. They said to call
technical support. Fair enough. I then called again and
chose technical support (option 4). I then waited 1/2 hour ON HOLD before I
hung up. I never talked to a human. My call was not screened. I then called
customer service, told them I couldn't get through. I was basically told that
my only two options were to buy the product or to try technical support again.
They wouldn't even take my number to call me back when things had calmed down.
I've been dealing with computer companies for many years and have never
run into this. Heck, people from Symantec have called me back in the past.

>If you have been a Think C user, you have a good feel for what any
>version of Think C will look like. The 60 day MBG is a great way to
>test drive the new version if you have some nagging unanswered
>questions.  It sounds like the person handled that part correctly given
>that tech support was not an option and this person did not have an
>answer for you.  May be she/he should have but they did not. They
>probably get 100's of calls a day and many of them from people that
>probably never planned to buy. They have to make a business decission
>about how to allocate their dollars.

I think you've missed the point. I couldn't talk to people that Symantec
said would answer my questions. I made, I think, a reasonable attempt to
do this. Or are you saying I should haved stayed on hold for longer than
a half hour.

>Faning the flames does not help anyone. If you don't like Symantec
>then you just don't like them. There are many people who still do.
>Except for some C++ bugs, Think C is still a great product.

Actually, I do like Symantec. I've spent lots of money with them in the
past and recommended their products to others. I was getting ready to
spend more money with them. You're clearly misreading my motives. I was
puzzled by this episode, plus a little pissed off. I can't believe you'd
feel any different if it happened to you.

>Again, give Phil some direct questions and see if that helps.

>Flame me if you want, I will not listen. I am tired of the petty
>complaints over the upgrage fees and what a bad product Think C
>has become. $150/$250 is cheap if you are doing real development
>and if you are just playing around, then stick with version 6.
>There are some of us that have to have one of each compiler so that
>the others can have development tools.

I don't intend to flame you. However, I hope you will listen to what I am
actually saying rather than reading in stuff based on other people's posts.
For instance, I never complained about the fee. I also explicitly said that
I may have hit a bad day for technical support and was willing to give
Symantec the benefit of the doubt. You should have read my message as an
invitation to Symantec to try to set things right with a long-time customer
who was, for whatever reason, treated very poorly. Symantec has taken me
up on this invitation: I just got a mail message Tom Emerson of Symantec
saying he would answer my questions.

Scott

>Bill


--
- -----------------------------------------------------------------------
Scott W. Haney        || Lawrence Livermore N'Lab || The above views are
[e-mail] || P.O. Box 808;  L-637     || mine and not neces-
[phone]        || Livermore, CA  94550     || sarily LLNL's.

+++++++++++++++++++++++++++

>From Chris Russo <[e-mail]>
Date: 30 Mar 1994 21:45:50 GMT
Organization: Sonic Systems, Inc.

In article <2nae7p$[e-mail]> Bill Stackhouse,
[e-mail] writes:
>In article <haney.764972035@maverick> [e-mail] (Scott W.
Haney) writes:
>>  I received a flier from Symantec advertising C++ version 7.0 and had
>>some problems parsing the marketing-speak description of the features.
>>Foolishly thinking that they'd be happy to help out a long-time
>>customer who was thinking about spending $250 on their products (7.0
>>upgrade + PPC kit), I thought I call them up to find out more about
>>these features. I called there NON-toll-free number and, after
>
>[bunch of complaints deleted]
>
>Phil Shapiro is a great resource and always gets a response back to me
>in short order. His email address is [e-mail]  If you
>read the programming group, you know about Phil. You should have tried
>him first since you probably knew that your questions were more
>technical than could be answered by a sales person. Did you do that just
>to have a reason to complain?

Bill, I don't think that you're being very fair with Scott.  The internet,
albeit an awesome resource, should not be a developer's only option when
confronted with a technical support problem.

Just as a reality-check, Scott, I had a problem VERY similar to the one
you had.  I wanted to call Symantec to report a few Source Server bugs and
to find out when the next revision was due.  After resolving the phone
alias that they give you in the manual, I waited on hold for _45_
minutes!!
Long distance, no less.  If it were an 800 number, I could maybe
understand;
but not even offering some type of callback service was a bit much.

After I got through to the tech support guy, I received only further
frustration.  He didn't know anything about ANY of the bugs that I was
wondering about. "Uh, we haven't encountered that one."  Yeah, right.
They only happen on several of our machines here with only BASIC use of
the Source Server stuff.

>Yes they handled the call very badly and I would have been pissed off.
>If you had had a real technical support question and not a sales question
>I bet you could have gotten it answered.

Well, I can say that I wasn't given any satisfactory answer.  I consider
my Technonsupport experience with Symantec to have been a total waste of
my time and my company's money.  I don't plan on going through it again
in the future.

>If you have been a Think C user, you have a good feel for what any
>version of Think C will look like. The 60 day MBG is a great way to
>test drive the new version if you have some nagging unanswered
>questions.  It sounds like the person handled that part correctly given
>that tech support was not an option and this person did not have an
>answer for you.  May be she/he should have but they did not. They
>probably get 100's of calls a day and many of them from people that
>probably never planned to buy. They have to make a business decission
>about how to allocate their dollars.

And WE have to make business decisions about how to handle ours.  I
wish I would have paid more attention to the net in the first place,
and I appreciate real life experiences as related by Scott Haney.  They
help me to make choices.  The only better teacher than experience is
other peoples' experience.

>Faning the flames does not help anyone. If you don't like Symantec
>then you just don't like them. There are many people who still do.
>Except for some C++ bugs, Think C is still a great product.

Once again, I appreciate reports like Scott's.  I don't think that he
was trying to fan any flames.  He was just trying to warn others by
relating his personal experiences.  There are many people out there
who value good technical support over other features of a product.
He might be saving those people a lot of frustration.

>Again, give Phil some direct questions and see if that helps.
>
>Flame me if you want, I will not listen. I am tired of the petty
>complaints over the upgrage fees and what a bad product Think C
>has become. $150/$250 is cheap if you are doing real development
>and if you are just playing around, then stick with version 6.
>There are some of us that have to have one of each compiler so that
>the others can have development tools.
>
>Bill

I, for one, don't consider his _complaints_ to be petty.

Chris Russo

Chris Russo
Macintosh Software Developer
Sonic Systems, Inc.                        [phone] Ext #107
Sunnyvale, California, US

+++++++++++++++++++++++++++

>From Joe Francis <[e-mail]>
Date: 31 Mar 1994 01:28:50 GMT
Organization: Smooth Roo Software

Bill Stackhouse, [e-mail] writes:
> Phil Shapiro is a great resource and always gets a response back to me
> in short order. His email address is [e-mail]  If you
> read the programming group, you know about Phil. You should have tried
> him first since you probably knew that your questions were more
> technical than could be answered by a sales person.

I think you need to rent a clue.  When you have technical questions
about a product, sales and/or tech support are the people in the business
of answering your questions.  Bugging the product engineers to do, on
their own time, what the support staff is paid to do, is not the correct
solution.

> Did you do that just to have a reason to complain?

Did you write this just to get flamed?

- ------------------------------------------------------------------------
No matter how subtle the wizard, a knife between the shoulder blades
will seriously cramp his style.
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Amanda Walker)
Date: Wed, 30 Mar 1994 16:02:27 -0500
Organization: InterCon Systems Corporation, Herndon, VA USA

[e-mail] (Bill Stackhouse) writes:
> Yes they handled the call very badly and I would have been pissed off.
> If you had had a real technical support question and not a sales
> question I bet you could have gotten it answered.

Rule Number One of Commercial Software: Do not piss off the customers.
Rule Number Two: See Rule Number One.

It doesn't matter if he was calling about the color of the box; Symantec
should have enough people to answer their phones.  There's more to selling
software than making pretty yellow boxes, after all.

> $150/$250 is cheap if you are doing real development and if
> you are just playing around, then stick with version 6.

Or just chuck it and use MPW...


Amanda Walker
InterCon Systems Corporation
--
"Ah, prune juice: a warrior's drink."    -- Star Trek: The Next Generation





+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: Mon, 04 Apr 1994 15:29:40 +0200
Organization: Computer Science Dept, U of Witwatersrand

In article <2nbb5f$[e-mail]>, [e-mail] (Jon Wtte)
wrote:

> Actually, I think you hit the bad product for Symantec.
> Symantec should be selling word processors, mail applications
> and project organization chart drawing programs, not development
> tools. They should separate out development tools into a whole
> subsidiary company, with its OWN support channels, management,
> marketing budget, ...
>
> That's about the only way they can believably stay at the forefront
> of the tools business.

It seems they did do this, only they didn't think to maintain a financial
interest in the new company - isn't a large chunk of the Metrowerks
Codewarrior project based on ex-Symantec people?
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone [phone]  fax [phone]

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Mon, 4 Apr 1994 19:56:14 GMT
Organization: The World Public Access UNIX, Brookline, MA

>It seems they did do this, only they didn't think to maintain a financial
>interest in the new company - isn't a large chunk of the Metrowerks
>Codewarrior project based on ex-Symantec people?

Actually, there are only 3 ex-Symantec employees at Metrowerks, plus Greg
Dow who did the TCL on contract for Symantec. Metrowerks itself has quite
a few more people than that.

-- John


+++++++++++++++++++++++++++

>From Stuart Cheshire <[e-mail]>
Date: 9 Apr 1994 16:47:29 GMT
Organization: Stanford University

In article <[e-mail]> John McEnerney, [e-mail]
writes:
>Actually, there are only 3 ex-Symantec employees at Metrowerks

Yeah, but WHICH three?

Stuart Cheshire <[e-mail]>
 * <A HREF="file://brubeck.stanford.edu/www/cheshire-bio.html">WWW</A>
 * Stanford Distributed Systems Group Research Assistant
 * Escondido Village Resident Computer Coordinator
 * Macintosh Programmer

---------------------------

>From [e-mail] (Interealm)
Subject: System 7 Pro & Drag Mgr.
Date: 2 Apr 1994 11:53:04 -0500
Organization: America Online, Inc. (1-800-827-6364)

Hi...

Can someone tell me what version of the Finder ships with System 7 Pro and
whether or not Sys7Pro comes stock with built in Drag Manager Support from the
Finder?

Thanks in advance...

Jack

+++++++++++++++++++++++++++

>From [e-mail] (Greg Landweber)
Date: 04 Apr 1994 22:15:41 GMT
Organization: (none)

In article <2nk7tg$[e-mail]> [e-mail] (Interealm) writes:
   Can someone tell me what version of the Finder ships with System 7 Pro and
   whether or not Sys7Pro comes stock with built in Drag Manager Support from the
   Finder?

System 7 Pro uses Finder 7.1.3, which supports the drag manager if the
Drag Manager is present.

System 7 Pro contains a limited version of the Drag Manager which is
used by Finder 7.1.3, but it cannot be used by any other application.

If you want other applications to support drag manager features, you
need the "Macintosh Drag and Drop" extension.

-- Greg "Browser" Landweber
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 5 Apr 94 13:00:13 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <2nk7tg$[e-mail]>, [e-mail] (Interealm) writes:
>
> Can someone tell me what version of the Finder ships with System 7 Pro and
> whether or not Sys7Pro comes stock with built in Drag Manager Support from the
> Finder?

System 7 Pro comes with Finder 7.1.3. This is the same version that supports
the Drag Manager Clipping Extension, Finder scripting, and QuickDraw GX beta 3.
By the way, the Power Macs come with Finder 7.1.4.

System 7 Pro has some kind of built-in Drag Manager, but I don't think the
API for that is available to ordinary mortals--you still need to install the
Drag Manager extension to get the public API.

That built-in Drag Manager is interesting: it lets you drag stuff about
in Finder windows without bringing the Finder to the front--not until you let
go the mouse button.

Lawrence
(trying to think of an excuse for wanting that feature in my own programs :-))

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 7 Apr 1994 00:51:21 GMT
Organization: Apple Computer

Lawrence D'Oliveiro, [e-mail] writes:
> That built-in Drag Manager is interesting: it lets you drag stuff about
> in Finder windows without bringing the Finder to the front--not until you
let
> go the mouse button.
>
> Lawrence
> (trying to think of an excuse for wanting that feature in my own programs
:-))

This is the preferred HI for draggable apps. You want to be able to drag
something from a background window without having that window immediately
come to the front and obscure your intended destination. Finder 7.0 fixed
this for the Finder->Finder drag situation, and with the Drag Manager they've
generalized it into an HI guideline for all apps.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

---------------------------

>From [e-mail]
Subject: Using PBCatSearch
Date: Tue, 5 Apr 1994 21:18:19 GMT
Organization: Drake University, Des Moines, Iowa, USA

I seem to be having a problem with a difference between the described
record in IM and what I actually find in the C interface libraries for the
Mac. Let me explain. I'm trying to access a field in a struct of CInfoPBRec,
I'm trying to access the ioNamePtr field in the record by using a CInfoPBPtr.
The problem is that whenever I compile the compiler says that there is no
such member in that struct. I looked in the C interface libraries for THINK
C and found that there is no ioNamePtr in the struct CInfoPBRec like
described in IM.

I'm trying to search a disk using PBCatSearch() and this is where I have ended
up. If you have any code or examples for this in C then please send them
to me. Thanks for any help.


                -Mike


+++++++++++++++++++++++++++

>From [e-mail] (Dale M. Greer)
Date: 5 Apr 1994 21:39:04 GMT
Organization: The University of Texas at Dallas

[e-mail] wrote:
> I seem to be having a problem with a difference between the described
> record in IM and what I actually find in the C interface libraries for the
> Mac. Let me explain. I'm trying to access a field in a struct of CInfoPBRec,
> I'm trying to access the ioNamePtr field in the record by using a CInfoPBPtr.
> The problem is that whenever I compile the compiler says that there is no
> such member in that struct. I looked in the C interface libraries for THINK
> C and found that there is no ioNamePtr in the struct CInfoPBRec like
> described in IM.

> I'm trying to search a disk using PBCatSearch() and this is where I have ended
> up. If you have any code or examples for this in C then please send them
> to me. Thanks for any help.

I found an example of using PBCatSearch at ftp.apple.com.  It looks
for a file by Type and Creator.  Once it finds the file, the name
is in csBlockPtr->ioMatchPtr[0].name.  Before searching, the field
csBlockPtr->ioSearchInfo1->hFileInfo.ioNamePtr is set to nil.  The
structure csBlockPtr is a CSParamPtr.  CInfoPBPtr begins with an
HFileInfo, which in turn begins with a ParamBlockHeader which
also contains an ioNamePtr.

I can send you the DTS PBCatSearch example or post it if you don't have
access to ftp.apple.com.

--

Dale Greer, [e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Allon Stern)
Date: Tue,  5 Apr 1994 23:51:31 -0400
Organization: InterCon Systems Corporation, Herndon VA.

In article <2nslpo$[e-mail]>, [e-mail] (Dale M. Greer)
writes:
> [e-mail] wrote:
> > I'm trying to search a disk using PBCatSearch() and this is where I
> > have ended up. If you have any code or examples for this in C then
> > please send them to me. Thanks for any help.
>
> I found an example of using PBCatSearch at ftp.apple.com.  It looks for
> a file by Type and Creator.  Once it finds the file, the name
> is in csBlockPtr->ioMatchPtr[0].name.  Before searching, the field
> csBlockPtr->ioSearchInfo1->hFileInfo.ioNamePtr is set to nil.  The
> structure csBlockPtr is a CSParamPtr.  CInfoPBPtr begins with an
> HFileInfo, which in turn begins with a ParamBlockHeader which
> also contains an ioNamePtr.

When writing your code, keep in mind that not all volumes support PBCatSearch.
The proper way to check to see if it is supported is to call PBHGetVolParams
and check the appropriate bit (bHasCatSearch = 7).

Reference: IM-Files pages 2-147 through 2-150


Also, on page 2-205 of IM-Files, it states:
"Not all volumes support the PBCatSearch function [...] even though AFP
volumes support PBCatSearch, they do not support all of its features that are
available on local volumes."

In other words, your mileage may vary 8^)

--
Allon


| Allon Stern        | 703-709-5557 |  Ring around the Internet    |
| [e-mail] |    KE4FYL    |  A packet with a bit not set |
+--------------------+--------------+  ENQ ACK ENQ ACK             |
|  All opinions above are my own.   |  We all go down!             |
|------------------------------------------------------------------|



+++++++++++++++++++++++++++

>From [e-mail] (Brian Bechtel)
Date: 9 Apr 1994 17:48:49 -0700
Organization: Apple Computer, Inc., Cupertino, California

[e-mail] writes:

>I'm trying to search a disk using PBCatSearch() and this is where I have ended
>up. If you have any code or examples for this in C then please send them
>to me. Thanks for any help.

ftp://ftp.apple.com/dts/mac/sc/morefiles.1.1.1.hqx

contains excellent sample code for using PBCatSearch, among other
functions.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

---------------------------

End of C.S.M.P. Digest
**********************